With respect to conventional computing environments (e.g., ActiveX Controls on Windows brand operating systems), in order for a programmer to create custom components, extensive knowledge of programming languages (e.g., C) is required. The advent of higher-level abstraction, object oriented (OO) environments (e.g., .NET Framework brand APIs) make it considerably easier to create custom components. However, utilizing these components in visual design environments (e.g., the .NET Framework brand Windows Forms Designer in a Visual Studio.NET brand development tool). In other words, the process of using these custom components has been somewhat cumbersome and not designer friendly.
With the introduction of the frameworks (e.g., .NET Framework brand framework), more and more users are exposed to object oriented design principals. One of these principles is inheritance. Inheritance makes it easy to create components that “inherit” the behavior and attributes of existing components in the system. Accordingly, as part of designing software built with the object oriented framework, it is common to create a new component that inherits or “derives from” an existing component. Within the existing visual designer environments (e.g., Visual Studio .NET versions 1.0 and 1.1 brand designers), in order to make controls available to be utilized within the visual designer, the user must navigate through several non-intuitive steps to populate the components onto the toolbox so that they can be placed within the visual design surface.
For example, in accordance with traditional systems, once a new control is built, the user opens an add/remove dialog box to add the new component to the toolbox. The add/remove dialog box is employed to identify desired controls. Often, the use of the dialog box requires knowledge of the location of the newly built control dynamic-link library (DLL). If not already available, a user must “browse” to locate the correct path to the control, and this location may not always be obviously apparent to all users.
Once the library is identified, any components within will be added to the list of available controls on the system. The user must then select with components(s) within the DLL to add to the toolbox. The add/remove dialog box may then be closed and the selected components or controls will be added to the toolbox. Finally, the control can be dragged from the toolbox to the form as desired. Clearly, this is a cumbersome process involving many time consuming non-intuitive steps.
What is needed is a system and/or methodology that can streamline and automate this toolbox population process. In other words, a substantial need exists for a system and/or methodology whereby upon building components (e.g., controls), automatic population of the toolbox is effected. Such a system would encourage a user to create custom components whereby they can be easily consumed and utilized from within the design time environment (e.g., toolbox). An additional need exists for a system that can automatically harvest all components (e.g., controls) within a system thus automatically (or selectively) inserting the identified components onto the toolbox for subsequent use and/or reference.